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Abstract 

We make monadic components more reusable and robust to changes 
by employing two new techniques for virtualizing the monad stack: 
the monad zipper and monad views. The monad zipper is a higher- 
order monad transformer that creates virtual monad stacks by ig- 
noring particular layers in a concrete stack. Monad views provide 
a general framework for monad stack virtualization: they take the 
monad zipper one step further and integrate it with a wide range of 
other virtualizations. For instance, particular views allow restricted 
access to monads in the stack. Furthermore, monad views provide 
components with a call-by-reference- like mechanism for accessing 
particular layers of the monad stack. 

With our two new mechanisms, the monadic effects required by 
components no longer need to be literally reflected in the concrete 
monad stack. This makes these components more reusable and 
robust to changes. 

1. Introduction 

Monads [15, 31] are a useful abstraction for encapsulating side- 
effects in purely functional languages like Haskell [18]. With mon- 
ads different types of effects - such as state, non-determinism or 
exceptions - can be modeled with the same abstract interface. 

Monads are composed via mechanisms such as monad trans- 
formers [13]. With monad transformers writing programs that use 
multiple effects is possible by stacking different transformers on 
top of each other to form a larger monad. Monads and monad 
transformers are interesting because they allow programmers to 
write realistic effectful programs that are still purely functional, 
thus enjoying reasoning principles such as equational reasoning 
and parametricity [21, 29]. Furthermore, because of these rea- 
soning principles, monads and monad transformers also provide 
a good setting for studying modular effectful components, like 
Aspect-Oriented Programming (AOP) style advice [17] or models 
of Feature-Oriented Programming (FOP) [20]. 

Monad transformers come with a responsibility: it is necessary 
to manage the monad stack. In Haskell there are two existing 
approaches for this: implicit liftings and explicit liftings. Implicit 
liftings exploit type-directed overloading of methods, provided by 
type classes [32], to automatically route an effectful operation to 
the first layer of the right type in the monad stack. Explicit liftings 


Permission to make digital or hard copies of all or part of this work for personal or 
classroom use is granted without fee provided that copies are not made or distributed 
for profit or commercial advantage and that copies bear this notice and the full citation 
on the first page. To copy otherwise, to republish, to post on servers or to redistribute 
to lists, requires prior specific permission and/or a fee. 

ICFP ’ll 

Copyright © 201 1 ACM [to be supplied]. . . $10.00 


offer more control to programmers, at the cost of automation, by 
allowing monadic components to directly refer to a monad layer at 
some position below the current layer using multiple invocations 
of the lift method (which moves from the current layer to the one 
immediately below). 

However, there are two main problems with the current mecha- 
nisms for manipulating the monad stack: 

1. Inconvenience: The first problem is that explicit lifting is sim- 
ply “awkward” to use. Explicit lifting relies on a positional 
mechanism, similar to de Bruijn indices, to refer to particular 
layers of the monad stack. Because access to the nth layer be- 
low the current layer requires n calls to the lift method, code 
quickly becomes polluted with lift method invocations. 

2. Lack of robustness, limited expressiveness and reusability: 

The second, and more fundamental, problem is that the current 
approach is not robust to changes and offers only limited ex- 
pressiveness and reusability, specially when higher-order com- 
ponents (or control flow operators) are involved. Implicit lift- 
ing through overloaded methods is robust, but it is also quite 
limited in expressiveness since handling multiple monads of 
the same type is not possible. Explicit liftings are not robust 
to changes because the relative (positional) references impose 
a tight coupling between monadic components and the monad 
stack, which makes those components less adaptable. Further- 
more, explicit lifting still has limited expressiveness because it 
only allows to refer to layers below the current layer, but not 
layers above. 

The first problem is well-known in the Haskell community and 
there have been some proposals for solving it. Piponi [19] and 
Snyder & Alexander [25] suggested a solution by labeling monad 
transformers with (type-level) tags, allowing particular layers in 
a monad stack to be accessed by name rather than by position, 
eliminating the pollution arising from multiple calls to lift. 

The second problem is a bit more subtle because it only shows 
up when monadic components are meant to be reused in differ- 
ent contexts with different monad stack layouts as, for example, 
in the modular effectful components studied by Prehofer [20] and 
Oliveira et al. [17], For this to be possible, monadic components 
should abstract over the monad stack by keeping the type represent- 
ing the monad stack polymorphic (though constrained). The use of 
names is also useful to solve this second problem because names 
are more robust to changes in the monad layout. However, existing 
tagged approaches [19, 25] are invasive, in the sense that monadic 
components have to be written specially with tagging in mind, and 
they still have reusability limitations (such as name clashes). 

Contributions This paper proposes two new techniques for ma- 
nipulating monad stacks: the monad zipper and monad views. The 
monad zipper is a monad transformer that allows ignoring particu- 



lar layers in the concrete stack. Monad views abstract the concrete 
monad stack into a virtual monad stack, which presents itself with a 
more suitable interface to a particular component. Views also allow 
restricting access (in the sense of permissions) to particular layers 
of the monad. An important characteristic of both techniques is that 
they can be used non-invasively, by being applied externally and 
effectively providing the component with a tailored virtual monad 
stack. When there are conflicts that are local to a certain compo- 
nent, monad views can also be used invasively to provide a call- 
by-reference mechanism to refer to particular layers in the monad 
stack. By working with virtual stacks, requirements of components 
in terms of the monad stack shape no longer need to be literally 
reflected in the concrete monad stack, making these components 
more reusable and robust to changes. 

We also briefly report on a non-trivial application of our tech- 
niques, developed by Schrijvers et al. [24], which shows that the 
techniques proposed by us scale well in terms of the number of 
monads in a monad stack. In that application 30 monadic compo- 
nents and equally as many monad transformers were used. We are 
not aware of any Haskell projects using as many transformers at the 
same time. 

2. Overview 

The presentation of our work will be made in Haskell, and we 
will assume knowledge of the language. Nevertheless, as discussed 
in more detail in Section 7.1, we believe that none of the main 
concepts presented by us (the monad zipper, views and masks) are 
Haskell-specific. 

In this section we briefly introduce the Haskell monad trans- 
former library (MTL), provide an overview of the current state-of- 
the-art in manipulating monad stacks and illustrate how the monad 
zipper and monad views improve upon that state-of-the-art by vir- 
tualizing the monad stack. 

2.1 Quick Monad Transformers Reference 

Our ideas and examples are formulated in terms of a variant of the 
MTL. 1 See Liang et al. [13] for a more in-depth introduction to 
MTL. Figure 1 summarizes the monad transformers, classes and 
operations that we use in the course of this paper. The transformers 
consist of pure computations (I T , the identity monad transformer) 
and computations with a read-only environment (K. T ), updateable 
state (§ T ) and exceptions (Et). These transformers are combined 
into different monad stacks with the identity monad (I) at the 
bottom. The type classes (denoted with subscript M) constrain a 
monad stack to provide support for a particular effect, without as- 
suming a particular stack configuration. Each class offers a number 
of primitive operations, such as ask to access the environment for 
Rm- 

2.2 Monadic Components 

An important distinction throughout this paper is between monadic 
component and client code. The main goal of this paper is to im- 
prove the robustness, reusability and convenience of use of the for- 
mer. At first sight, it will seem that the client code pays the price for 
this improvement, because it is forced to make the necessary con- 
figuration choices for the more adaptable components. Fortunately, 
the complexity can be neatly hidden behind combinators. 

Component code Component code is intended to be reused in 
different contexts. Typically such code resides in libraries, which 
are used by clients in various different applications. As two simple 
examples of monadic components, consider an incrementer and an 
assertion checker: 


1 Section 7.2 discusses the differences. 


inc : : S M Int m => m Int 

inc = do j.v <— get ; put ( x + 1); return (x + 1)) 

assert :: E M String m => Bool — > m () 
assert test = if test then return () 

else throwError "Assertion failed" 

What is interesting about these components is that they can be 
adapted to work with different concrete monad stacks. This is 
possible because we use parametric polymorphism to abstract over 
the monad, imposing only the required restrictions on the layout by 
using (type-class) constraints. For example, what the signature of 
inc tells us is that it can be used by any client whose monad stack 
supports state. 

Components can. of course, be combined into larger compo- 
nents. For example: 

comp :: (S M Int m, E M String m) => m () 
comp = do j .r <— inc; assert (x > 0) ) 

Client code Client code instantiates the monad stack, and is de- 
fined by the end-user when using the components to build particular 
applications. Different stack configurations may be possible: 

type M] = § T Int (E T String I) 
type M 2 = E t String (S x Int I) 

In general, different monad stack layouts have different semantics. 
Consider the following run functions for Mj and My. 

runM j :: Int —* Mj a —* Either String (a, Int) 
runM i n = runl o runE^ o flip runS T n 
runM 2 :: Int — * M 2 a — » ( Either String a, Int) 
runM 2 n = runl °flip run§ T n o runE T 

When we use these functions to instantiate the monad in comp 
we can observe the semantic differences between the two monad 
stacks: 

> runM i (-1) comp 

Left "Assertion failed" 

> runM 2 (-1) comp 

(Left "Assertion failed", 0) 

In the case of Mi changes to the state are lost upon throwing an 
error, while this is not the case for M 2 . 

2.3 State-of-the-art Manipulation of the Monad Stack 

Implicit lifting The monadic components presented in Section 2.2 
use implicit lifting for accessing the right layer in the monad stack. 
Effectful operations like get, put or throwError are automatically 
routed to the first layer of the right type in the monad stack, by 
exploiting the type-based overloading mechanism of type classes. 
This approach is robust, because the routing automatically adapts 
to multiple layouts of the monad stack (such as Mj or M 2 ). 

Implicit lifting has one big limitation: it is ineffective for com- 
bining multiple instances of the same effect because the automatic 
type-based selection of a monad layer always picks the first layer 
of the right type. If there is another layer of that type below that 
layer, implicit lifting cannot access it. 

Explicit Lifting Explicit lifting addresses the limitation of implicit 
lifting to some extent because it allows moving down the monad 
stack into a lower layer. Therefore, by calling the effectful opera- 
tions in lower layers, implicit liftings are routed to monad trans- 
formers that are not at the top of the stack. 

The approach consists of using lift methods explicitly to disam- 
biguate the targets of accesses to the monad stack. Suppose that 



— identity transformer 

— identity monad 

newtype I T m a 

newtype I a 

I T :: m a — > I T m a 

I :: a — * I a 

runlj : : I T m a — > m a 

runl 

— reader transformer 

— reader class 

newtype R T e m a 

class Monad m => R M e m \ m — » e 

R T :: (e — » m a) — * R T e m a 

ask :: R M e m => m e 

run R t :: R T e m a — > e > m a 


— state transformer 

— state class 

newtype S T s m a 

class Monad m => S M s m \ m —> s 

§ T :: (,s- — > m (a, s)) — » § T 5 m a 

get :: S M s m =^> m s 

runS T :: § T s m a — > s — > m (a, s ) 

put :: § M s m => s — > m () 

— exception transformer 

— exception class 

newtype E T x m a 

class Monad m => E M x m \ m — > x 

E t :: m ( Either x a) — » E T x m a 

throwError ::E M M=>.t-* m a 

n<»E T : : Bp x m a — » m ( Either x a) 

catchError : : E M x m => m a — » (x —> m a) — > m a 



Figure 2. Three composition scenarios: ifpos inc , ifpos ( lift inc) and f (ifpos (J, inc)). 


we want to combine two instances of inc in such a way that they 
update different counters. Using explicit lifting we could write a 
component doublelnc that does the job: 

doublelnc :: (S M Int (t m ), S M Ini m, MonadTrcms t) => t m () 

doublelnc = inc > lift inc > return () 

The role of lift is to ensure that the second instance of inc updates 
a counter in the monad below the current layer (and not at the top- 
most layer). The use of lift is reflected in the constraints imposed on 
the stack. In this case, the requirement is that the top-level monad 
t m must support state and the monad m below must also support 
state. If the monad stack is § T Int (§ T Int I), then doublelnc 
updates the two state layers. Hence, running doublelnc with the 
run function below yields the result (((), 1), 6). 

run c = runl $ runS T (runS T c 0) 5 

Explicit lifting is essentially, like de Bruijn indices, a relative refer- 
ence mechanism: it allows moving n layers below 1 the current layer 
by using n calls to lift. 


-Note that there are two points of view for lift m in a certain calling 
context. From the calling context’s point of view towards m the direction 
of movement is downwards, while, vice versa, the direction of movement 
from ill's point of view towards the calling context is upwards. Usually, we 
adhere to the calling context's point of view, but occasionally we may have 
to use m’s perspective; when that is the case, it should be clear from the 
context. 


A clear limitation of this mechanism is that it is not possible 
to refer to layers above the current layer. Yet this functionality is 
particularly desirable to preserve modularity when higher-order 
components (also known as control flow operators ) are involved. 
Some compositions of primitive monadic control flow operators 
(e.g. catchError ) cannot be expressed with lift at all. Furthermore, 
components that use lift internally usually impose unnecessary 
restrictions on the layout of the monad stack, because they express 
relative orderings of layers. 

In summary implicit liftings are quite robust to changes and 
are convenient to use, but have limited expressiveness; and, while 
explicit liftings address the limitations of implicit liftings to some 
extent, they too are still limited in expressiveness and there is a 
price to pay, in terms of a tighter coupling between component and 
monad stack. 

2.4 Virtualizing the Monad Stack 

By presenting the component code with a virtual monad stack, 
components become decoupled from the client code’s concrete 
monad stack. The monad stack virtualization is achieved by: 

1. avoiding lift method invocations inside component code, which 
are responsible for the tight coupling; and 

2. using the monad zipper and monad views to manage virtual 
monad stacks. 

In this section we explain how the monad zipper and monad views 
are used to develop components free of lift invocations while, at 
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Figure 3. The monad stack M and the layers visible through masks 
nij, m 2 and m 3 . black layers are masked and gray layers are ab- 
stracted over. 


the same time, allowing for additional expressiveness that is not 
possible with explicit lifting alone. 

Note that, in the remainder of this section, the intention is just 
to demonstrate how the monad zipper, structural masks, nominal 
masks and views can be used from the user’s point of view to solve 
various problems related to the manipulation of monad transform- 
ers. The reader is not expected to understand in detail how the ex- 
amples work by the end of Section 2. Instead, the details of each 
mechanism will be explained in later sections: Section 3 describes 
how the monad zipper works, Section 4 presents views, and Sec- 
tion 5 presents the different flavors of masks. 

The Monad Zipper With the monad zipper we derive a virtual 
stack from a concrete one, that ignores a prefix but does not forget 
it. For instance, M 3 is a virtual stack for § x hit (§ T Int I) that 
ignores, but does not forget, the topmost transformer: 

type Mj = (§ T hit > § T hit) I 

Ignoring a prefix enables an operation f much like lift, while 
still enabling an inverse J, that has no counterpart in the explicit 
lifting approach. This is useful for adapting higher-order monadic 
components such as ifpos 

ifpos :: § M Int m => m Int — > m Int 

ifpos c = do {x <— get', if x > 0 then c else return 0) 

(which routes the flow of control to c when a state is positive) 
to monad layouts where the component c is supposed to access a 
monad above the current layer. With the monad zipper this problem 
is solved as follows: 

> run (t ( ifpos (J, inc))) 

((1, 1), 5) 

Without the monad zipper, the only way to achieve the same result 
is to invasively (non-modularly) modify ifpos such that the get 
method is lifted: explicit lifting alone is not enough to handle 
the scenario on the right of Figure 2. The zipper, on the other 
hand, allows ifpos to be reused without any invasive changes to 
the original code. 

Structural Masks Masks take the monad zipper one step further 
and allow selectively ignoring stack layers at multiple arbitrary po- 


sitions in the monad stack (not just prefixes). Consider for instance 
the monad stack 

type M = § T hit (§ T Int (E x String (E x String I))) 

to which the two components ifpos and comp > get have interleaved 
access in the composition 

client M Int 

client = from mi (ifpos (to mi (from m 2 (comp > get)))) 

where mi = ■ 

m 2 = □ 

Here, the mask m 2 = □ ::: ■ ::: ■ ::: □ has a meaning similar to 
the bitvector 1001. When imposed on a monad stack, it ignores the 
second and third layers. The from m and to m functions, with m a 
mask, generalize T and J,. For instance, from m 2 comp gives comp 
access to the first and fourth layer in a monad stack. Similarly, 
mj provides ifpos with access to the second and third layers. See 
Figure 3 for a graphical depiction. Note that the layers in gray 
are not masked for the corresponding component, but nor is that 
component aware of their presence. This is either because a visible 
layer higher up in the monad stack blocks a similar layer lower 
down from view, or because the component’s polymorphic type 
does not mention (i.e., abstracts away) the effect of a layer. 

Masks with Restricted Views Masks are special instances of a 
more general mechanism called views. As such, masks can be freely 
combined with other types of views. For instance, the following 
example shows how to use masks in combination with a read-only 
view r 2 , which provides a read-only view of a state monad. 

client' M Int 

client' = from m 2 ( ifpos (to m 2 (from m 2 comp > from m 3 ask))) 

where mi = ■ 

m 2 = 
m 3 = n 

The ask component, whose type is R M e m => m e (see also 
Figure 1), requires a reader monad, but the concrete monad M has 
no layer with a monad of that kind. However, we can view one of 
the state monads as a reader. The read-only view r 2 , used in the 
mask m 3 , does precisely this and allows the component ask to view 
the first state monad in M as a reader monad. 

Nominal Masks Referring to layers in a structural fashion (with 
the monad zipper or bitvector-like masks ) can be fragile when the 
layout of the monad stack is likely to change. With a nominal mask, 
the client code specifies the names (not the locations) of the layers 
to be used by a component. That component is then automatically 
matched up with the correspondingly named layers in the monad 
stack. For instance, with nominal masks the client example would 
be rewritten as: 

client" = ifpos ((comp > get) ‘ use ‘ ( Counter j &Err 2 )) 

Here, Counter i and Err 2 are the names of respectively the first and 
fourth stack layer. The combinator use takes a list of names and 
makes the layers tagged with those names visible to the compo- 
nents. The list of names is assembled using the combinator & . The 
nominal masking infrastructure is built on top of structural masks. 
The big benefit of using the nominal approach instead is that it is 
much more robust: if the layers are rearranged, the nominal masks 
do not have to change at all. 

Call-by-reference with Views A final application of views and 
masks is to allow for a call-by-reference programming style (that 
is discussed in Section 5.3) in which the view arguments act as 
references to particular layers in the monad stack. 



add :: ( Monad m, § M Int n 3 , S M Int n 2 ) 

=s> (iij tx in) — » (n 2 x m) — » m () 
add xref yref = do x <— gef v xre/ 

y <- y«/ 

put v xref (x + y) 

In this example xref and yref are two view arguments and the get v 
and put v operations, which generalize the state monad get and put 
operations, use such views to access the right layer in the monad 
stack. This functionality is especially useful when a component 
employs multiple instances uses of the same effect. By using this 
call-by-reference style it is possible to avoid the pollution and the 
ordering constraints on the stack imposed by lift methods. 

3. The Monad Zipper 

This section presents the monad zipper: a monad transformer that 
is used to shift the focus of automatic lifting to the desired layer in 
the monad stack. In essence, the monad zipper allows us to ignore 
layers at the top of the stack while, at the same time, preserving 
these same layers, which allows shifting the focus back to the top 
when needed. 

3.1 Stacks and Zippers 

Sometimes type-level problems get easier when we move them to 
the term level. Let's reify the structure of the monad stack in a data 
type 

data Stack = Trans ■ Stack | Bottom Monad 
data Trans = T, | ... 7„ 

data Monad = I 

where the T, represent the different transformers and / represents I. 

Huet [9] taught us how to shift the focus to any position in a 
data structure, with his zipper. Here is the Zipper for Stack. 

data Zipper = Zipper Path Trans Stack 
data Path - Path ► Trans \ Top 

where Zipper pis denotes a stack with layer l in focus, remainder 
of the stack s and path p back to the top of the stack. The path is a 
reversed list, where the first element is closest to the layer in focus 
and the last element is the top of the stack. With a little syntactic 
sugar 

(>) = Zipper 

we obtain the self-explanatory notation {Top ► 7? ► T 2 ► T ? t> 
T 4 ) {T 5 ■ I), where the triangles point towards the layer in focus T 4 . 

The zipper function turns a stack into a zipper with the first 
element in focus: 

zipper :: Stack — > Zipper 
zipper (t ■ s) = (Top > t) s 

while the up and down functions allow shifting the focus one 
position up or down: 

up, down : : Zipper — > Zipper 

up ( Zipper (p ► tj) t 2 s) = (p > tj) (t 2 ■ s) 

down (Zipper p tj (t 2 • 5)) = ( p ► tj > t 2 ) s 

It’s all well and good to zip around a reified form of the monad 
stack, but can we do it on the real thing too? 

3.2 Monad Zipper 

The answer is yes. Here is how the monad zipper (i>) is defined: 
newtype (tj > t 2 ) m a = Z T {rnnZp :: tj (t 2 m) a j 


where the type (p>t) s has similar meaning to the reified data struc- 
ture above. However, the monad zipper only changes the type rep- 
resentation: the newtype indicates that no actual structural change 
to the monad stack ti (t 2 m) takes place. The only change takes 
place in the form of the type, which will enable us to select a dif- 
ferent type class instance depending on the layer in focus. We will 
see more on this later, but first let us complete the analogy between 
types and terms. 

Term-level stack composition (•), as in Tj - Mi, corresponds to 
type application, as in tj m 3 . As to ►, the type system will not 
allow terms of type Zipper to be used when terms of type Stack 
are expected. This segregation is not the case at the type level: the 
monad zipper type (>) can appear as part of a monad stack. Indeed, 
we define tj t> t 2 to be the monad transformer composition of tj and 
t 2 '. 

instance (MonadTrans t j , MonadTrans t 2 ) 

=> MonadTrans ( tj > t 2 ) where 
lift = Z T o lift o lift 

Hence, at the type level, we simply use > where ► was needed 
at the term level. So. the monad stack representation (?;>••• > 
tf) (t i+ 1 • • • m) denotes a monad stack with focus on f,. 

Finally, analogous to what the zipper function does with Stack, 
a monad transformer stack can be transformed into explicit zipper 
form by the following function: 

zipper : : t m a — > (I T > t) m a 
zipper = Zp o I T 

where the identity monad transformer I T acts as the Top sentinel. 

However, the I T sentinel is unnecessary, as the unadorned 
monad stack t m a already expresses that the focus rests on t. 
There is no point in adding I x to subsequently ignore it again with 
I T > t. In general, tj (t 2 ■ ■ ■ (tn m)) represents a monad stack with 
focus on tj. So we will not actually use the above zipper function. 

In summary, the term (Top ► Tj ► T 2 ► T 3 > T 4 ) (T s ■ I) is the 
reified form of the type (ti 1 > t 2 > t 3 > tf) (fj I). 

Relative Navigation Suppose we have a monad transformer stack 
1 1 (t 2 • • • ( t„ m)). Then the focus lies by default on the top-most 
transformer t 3 . The monad zipper becomes useful only when we 
shift the focus away from // to t 2 . The constructor Zp accomplishes 
that shift of focus, but how can we navigate further down, and back 
up? 

Let us start with moving the focus one step further down: 

step2to3 ::(t] > t 2 ) (t 3 m) a — 1 (tj > t 2 > tf) m a 
step2to3 = Z T 

A further step down: 

step3to4 :: (ti>t 2 >t 3 ) (t 4 m) a — > (t]>t 2 >t 3 >t 4 ) m a 
step3to4 = Z T 

The pattern should now be obvious. A single step down at any 
position in the stack is defined as: 

i'.'.ti (h m) a — > (f; > t 2 ) in a 
i=Zr 

Stepping back up is similar: 

T :: (t 3 > t 2 ) m a — > t 3 ( t 2 m) a 
1 = n/nZp 

Finally, note that J, o 1 = id and | 0 I = id hold. 

Focused Behavior So far, all we have seen is notation. The in- 
teresting behavior of tj > t 2 , where it should deviate from a plain 
monad transformer composition, lies in the methods of the monad 
classes, e.g. put of S M - For looking up the method implementations 



it should ignore (look through) ti and only consider t 2 m. This is 
achieved, e.g. for the state monad § M defined in Figure 1, by lifting 
the operations through tj : 

instance ( MonadTrans f/, MonadTrans t 2 . Monad m, S M s O 2 m)) 
=> S M s ((ti > t 2 ) m) where 
get = Zt $ lift $ get 
put = Zp o lift o put 

Contrast this with GHC’s newtype deriving construct, that would 
adopt the same behavior for (tj >t 2 ) in as for tj ( t 2 m), e.g., defining 
the former’s get in terms of the latter’s as Z T get. 

In order to generally characterize the required behavior of 
monad subclass instances such as the above one for § M , we im- 
pose the following law. 

Law 1 (Lift Compatibility). Given any monad subclass constraint 
Cm and any computation in this monad subclass x :: V iii.Cm m => 
m A, for any type A. Then we must have that 

T (x :: (T, > T 2 ) M A) = lift (x :: T 2 M A) 

for any monad transformers Ti and T 2 , and monad M such that 
C M (T 2 M) holds. 

Observe that this law holds for the above S M instance. 

As we have no space to provide the details of all monad trans- 
former instances for the monad zipper, we refer the interested 
reader to our implementations using our variant of the MTL library 3 
and the Monatron library [10]. 4 5 

In summary, like explicit lifting, the monad zipper allows us 
to shift the focus to layers below the current focused layer via f. 
However, unlike explicit lifting, we can also shift the focus to layers 
above the focused layer with J,. As we saw in Section 2.4 the extra 
expressiveness of the monad zipper allows for applications which 
are not possible with explicit liftings. 

4. Views 

The general problem we face when composing effectful compo- 
nents is that of incompatible assumptions about the monad stack. 
The solution is to work with one concrete monad stack, but to 
present each component with a suitable virtual monad stack. The 
correspondence between the concrete and virtual monad stack is 
captured in a view. 3 In Section 5 we will see how the views frame- 
work benefits from the monad zipper. 

4.1 Virtual Views as Monad Morphisms 

Semantically, a view corresponds to the categorical notion of a 
monad morphism (also called monad transformation in category 
theory, not to be confused with Haskell monad transformers that are 
a special case). Because we will be using different representations 
for monad morphisms, we capture the essential features in the 
MonadCategory type class. 

class MonadCategoiy (~») where 
idM {Monad m) => m m 
(•) :: (Monad l. Monad m. Monad n) 

=> (m n) — > (/ m ) — » (/ n) 

hmap :: (Monad m. Monad n, MonadTrans t) 

=> (m ri) — » (t m t n) 

from :: (Monad m. Monad n) => (n m) —* n a —* m a 

The MonadCategory class describes a category with monads as 
objects and monad morphisms as arrows. The identity and cornpo- 

3 http: //users.ugent .be/~tschrijv/Haskell/MTLzipper . tgz 

4 http: //hackage.haskell .org/package/Monatron 

5 Not to be confused with Wadler's notion of view [28], 


sition of the category are Mm and (•), which satisfy the right and 
left identity, and associativity laws: 

v • id M = v 
id M • v = v 

Vj • (V 2 • Vj) = (Vi • v 2 ) • v 3 

A Haskell monad transformer t corresponds to an infinite num- 
ber of monad morphisms in a particular representation 

{from -1 lift :: m t m \ m e Monad ) 

At the same time not all monad morphisms can be expressed by 
means of Haskell monad transformers. For instance, R T I § T I 
does not reflect the application of a monad transformer to a monad. 

What characterizes Haskell monad transformers is that they 
ate functors over monad morphisms, and hmap allows mapping a 
morphism through a monad transformer, which satisfies the functor 
laws: 

hmap idM = Mm 
hmap (v 2 • Vi) = hmap v 2 • hmap Vj 

The from function applies a monad morphism to a monadic com- 
putation. A monad morphism preserves the monad structure. 

from v o return = return 

from v (x >= /) = from v x >= from v o f 

4.2 Uni-directional Views 

Uni-directional views constitute the obvious implementation of 
MonadCategory. 

newtype n x m = Uni (Va.n a — > m a) 
instance MonadCategoiy (x) where 
idM = Uni id 

v 2 • v 1 = Uni %from v 2 ofrom v 2 

hmap v = Uni $ tmap (from v) 
from (Uni v) = v 

The above implementation is mostly straightforward, but we 
require a new operation tmap supported by all monad transformers 
to implement hmap. To avoid interrupting the flow, we continue 
with uni-directional views and refer to Section 7.2 for details on 
tmap. 

The lift function is the most prominent example of a uni- 
directional view, which turns a monad transformer into the uni- 
directional view presentation: 

liftv :: (MonadTrans t. Monad m) => m x t m 
liftv = Uni lift 

Uni-directional views for restricted access Uni-directional views 
are useful to restrict access to monadic layers that are shared by 
multiple components. For example, suppose we wanted to provide 
particular components only with read access to a shared state. The 
view rj can be used to achieve this. 

r 3 :: (MonadTrans t, Monad m, § M s (t m)) => R T s mx t m 
r 3 = Uni (An — » do { j «— get\ lift $ runR T n j)) 

In this case the monad transformer t can be any state monad trans- 
former (in particular it can be § T v). 

4.3 Bi-Directional Views 

Some views are invertible. An invertible view is a monad isomor- 
phism, or bi-directional view. We capture bi-directional views in a 
separate datatype. 

data n x m = Bi { fronts :: Va.n a — > m a 
, fo M :: ia.m a — > n a] 



A bi-directional view is of course an instance of MonadCategory. 

instance MonadCategory (tx) where 
Mm = Bi j fronts = id 

, to M = id ) 

v? • Vj = Bi { from M = from M v 2 ° from M v 2 

, to M = to M V] o to M V2 1 

hmap v = Bi [from M — tmap (from v) 

, to^ = tmap (to v) ) 
from v =from M v 

to :: ( Monad n. Monad m) => n tx m —* m a —* n a 
to = to^ 

inverse :: ( Monad n, Monad m) => n tx m — > m tx n 
inverse (Bi from to) = Bi to from 

where 

v • inverse v = idu = inverse v • v 
Abstract view constructor To abstract from the Uni and Bi repre- 
sentations of bi-directional views, we provide an overloaded view 
constructor function. 

class MonadCategory (~») => View (~») where 

view :: (Va.n a — » m a) — > (Va.m a — > w a) — > n m 

instance View (x) where view f f^ 1 = Unif 
instance View (tx) where view f f~ l = Biff~ l 

Using this constructor has the advantage that we can build over- 
loaded views that work not only as bi-directional views, but also as 
uni-directional views. This is useful to capture isomorphic views 
like: 

statelso :: ( Monad m. View (~»)) 

=> (S 2 — * Si) —* (si — > s 2 ) — > St s 2 m S T Si m 
statelso f f' 1 = view ( isoff ( isof~ 1 f ) where 

iso g h m = S T $ Tsj — » do (a, S;) <— run§ T m ( h s 2 ) 
return (a,g sf 

without committing to bi-directional views in particular. In this 
case statelso converts between S T S; m and S T S 2 m where si 
and S2 are isomorphic. This is useful, for instance, to share a state 
between components that expect values in different units, or to 
employ different character or data encodings. 

Isomorphic Read-Only Views Consider how we can turn the uni- 
directional read-only view r/ into a bi-directional one. For that 
purpose, the target type R T s m is unsuitable because it cannot 
keep track of updates. So we need to alter the target type for bi- 
directional read-only views. Fortunately, components are typically 
polymorphic in the monad stack and do not particularly care about 
a R t view; any instance of R M will do. We may put this freedom to 
good use by defining our own instance that is (trivially) isomorphic 
with any state monad. 

newtype S m Rt s m a = § m Rt {rwnS M Rr m a) 
instance § M 5 m => R M s (§ M R T s m) where 
ask = § m Rt get 

instance MonadTrans (§ m Rt s) 
r :: (S M s m. View ('■'->)) => S M R T 4 1 m m 
r = view ™«§mR.t SmRt 

5. Masks 

The operations on views presented in Section 4 can be seen as 
the foundation for a masking language for monad transformers. 
Using this masking language it is possible to apply a mask to a 


particular monad stack to hide, restrict access or grant full access 
to the various layers in the monad stack. 

5.1 Structural Masking 

Consider again the example program of Section 2.4 where two 
components, ifpos and comp > get , access disjoint layers in the 
monad stack M. 

type M = § T Int (S T Int (E x String (E T String I))) 

The former component accesses the second and third layer, while 
the latter component accesses the first and fourth layer. The snag is 
that the same state monad transformer type is used for the first and 
second layer, and the same error monad transformer for the third 
and fourth layer. 

The repeated transformer types suggest to use the monad zipper, 
but there is a complication. So far we have used the monad zipper 
to create a single focal point, ignoring a prefix of the monad stack. 
What we need now are multiple focal points, ignoring arbitrary 
parts of the monad stack inbetween. We achieve this by composing 
multiple zippers into a single view. We call such a view a structural 
mask, a mask because it hides particular layers of the monad stack, 
and structural because the form of the mask follows the structure 
of the monad stack (we will see non-structural masks later). 

To facilitate writing structural masks, we formulate them in 
terms of two primitive (1-layer or 1-bit) masks □ and ■, and one 
combinator (:::) that associates to the left. 

The symbols □ and ■ denote respectively a transparent and an 
opaque mask, similar to role the bits 1 and 0 play in a bit mask. In 
our approach, □ means as much as “I want to see the current layer 
of the monad stack” and ■ means “I don't want to see the current 
layer”. The (:::) combinator, that associates to the left, adds a 1-bit 
mask at the front of an n-bit mask, similar to the list cons operator 
( 0 . 

The views framework of Section 4 provides the appropriate 
infrastructure to implement the mask primitives: The □ mask is 
nothing more than the identity isomorphism. 

□ :: (Monad m. View ( ,N ->)) => m m 

□ = id M 

The ■ mask captures another familiar isomotphism, that of the 
monad zipper. 

■ :: (MonadTrans tj, MonadTrans 1 2 , Monad m. View ( ,N ->)) 

=> (t 1 > t 2 ) m t 2 (t 2 m) 

■ = view t i 

Finally, the composition operator is: 

(:::) :: (Monad m, Monad n 

, MonadTrans 1 1 , MonadTrans t 2 . View 
=> (ti n t 2 n) (m n) — > (f; m t 2 n) 

Vj ::: V 2 = v 2 • hmap v 2 

So a mask that hides the second and third layer is 

m 2 :: ... => t, (((t 2 i> t 3 ) > t 4 ) m) t, (t 2 (t 3 (t 4 m))) 
m 2 = 

Similarly, we could write a mask that hides the first and fourth layer 
as However, the much shorter 

mj ••• => (ti > t 2 ) m ti (t 2 m) 

nii = ■ 

has exactly the same effect in this example. In conclusion, the 
desired composition is 

client :: M Int 

client = from m 2 (ifpos (to mi (from m 2 (comp > get)))) 



5.2 Nominal Masking 

While the structural masking approach above resolves the issue 
of focusing on different layers, it can be awkward to use and 
maintain. Masking the stack requires global structural knowledge 
of the monad stack that is fragile with respect to changes. When the 
stack layout changes, all masks have to be adjusted accordingly. 

As a remedy, we propose a nominal masking technique. A 
nominal mask specifies the names rather than the positions of the 
monad stack layers that a component may access. The layers in the 
monad stack are correspondingly tagged with these names. Using 
the names and the tagged stack structure, the appropriate structural 
masks are automatically derived. This makes the approach much 
more robust: when the stack layers are reorganized (e.g. to insert a 
new layer or to swap two layers), the structural masks are adjusted 
accordingly. 

Tagged Monad Stack The T t tag monad transformer labels a 
particular position in the monad stack with a type-level name tag. 

newtype T t tag m a = T t j runT T : : m a j 
instance MonadTrans (T t tag) where 
lift = T t 

which can be combined with other monad transformers, e.g. S T to 
create tagged transformers. 

type TS t tag s m = T t tag (S T i m) 

runTS T :: Monad m => tag — » s — > TS t tag s m a — > m (a, s) 
™hT§t t s m = runSj (n«? 1 T m ) s 

Singleton types are used for tag names, e.g. 

data Counter ] = Counter i 
data Counter = Counter 

The type class TWith tag n m relates a monad stack n with a 
particular mask m that puts the focus on the layer with name tag. 

class ( Monad m, Monad n) => TWith tag n m where 
structure :: View (p-*) => tag — * (n m) 

We refer to Appendix A for the instances implementing TWith ; 
these automatically derive the appropriate structural mask. 

Two convenient additional combinators are 

use :: TWith tag n m => n a — > tag — > m a 
c ‘use‘ name = fronts ( structure name) c 
expose :: TWith tag n m => m a — * tag — > n a 
c ‘ expose ‘ name = ( structure name) c 

Hence, we may write 

c = do inc Tise‘ Counter j 

( inc > inc) ' use ‘ Counter 2 
return () 

to configure a number of incrementers. The stack layout is easily 
modified without requiring changes to the component configura- 
tion. 

> runl $ hmTSt Counter ■> 5 S runTBj Counter 1 0 S c 

((0,1), V) 

> runl $ runTSj Counter j 0 S runT§ T Counter 5 S c 

(( 0 , 7 ), 1 ) 

The above approach can be extended from masking with a 
single tag to masking with a type-level list of tags. For instance. 
Counter 1 & Error] represents a mask that views both layers 
Counter] and Error], Here, (&) is the constructor for non-empty 
type-level lists. We refer to the source code for all the necessary 
definitions. 


Moreover, it nicely integrates with the other views. For instance, 
statelso f f~ l • structure Counter selects the layer named Counter 
and applies a state isomorphism to it. 

5.3 Formal Mask Parameters 

So far, we have applied masks, and views in general, on compo- 
nents in a non-invasive fashion, from the outside. However, views 
as formal parameters within components also have an important 
use in disambiguating different instances of an effect. Obviously 
externally applied views are no solution to this problem that al- 
ready manifests itself inside a component. The traditional solution 
to disambiguate two different states within a component is to use 
lift. 

Consider again the doublelnc example in Section 2 . To disam- 
biguate the two states, we have used lift. Unfortunately, such in- 
ternally motivated uses of lift impose unnecessary ordering con- 
straints: in the monad stack one state transformer must appear 
above the other. Reversing the order of the two transformers is not 
possible; for that purpose we need to change the component imple- 
mentation or write an alternate version. 

Explicit view parameters allow us to abstract from the ordering, 
similarly to tagged transformers [ 19 , 25 ] but with two advantages: 

(i) we get the full expressivity of views for adapting the concrete 
monad stack, and (ii) we get the full expressivity of bi-directional 
views for handling mutual embedding of components. 

doubleInc2 :: ( MonadCategory (~»), § M Int nj, S M Int 112, Monad m) 
=> (ti] m) — » (j?? m) — > m Int 
doublelnc 2 \’i \’2 = do from Vi inc 
from v? inc 

So doubleInc2 □ ■, doubleInc2 ■ □ and doubleInc2 □ □ express 
both orderings of two disjoint states as well as a single shared state. 

Call-by-reference Operations It is possible to create variants of 
effectful operations that take a view argument. For example, the 
get v and put v operations used in the add example in Section 2 are 
defined as: 

get v v = from v $ get 
put v v = from v ° put 

6. Case Study: Monadic Mixins 

This section illustrates the uses of the monad zipper and monad 
views on monadic mixins. Because monadic mixins are higher- 
order components with non-trivial control flow patterns, traditional 
mechanisms to manipulate the monad stack do not provide ade- 
quate support. However, with the monad zipper and monad views, 
the complex control-flow patterns of monadic mixins do not pose a 
problem. 

6.1 Monadic Mixin Components 

Mixins We briefly summarize the notion of mixins, and refer the 
interested reader to previous literature on the topic for a more in- 
depth treatment [ 4 ], A simple form of mixins can be easily imple- 
mented in Haskell as follows: 

type Mixin s = s — > s 

fix :: Mixin s s 
fix a = a (fix a) 

(©) :: Mixin s — » Mixin s — > Mixin s 
a] © O] = Aproceed — * a t (a 2 proceed) 

The type Mixin s is a synonym for a function with type s — > 
s representing open recursion. The parameter of that function is 



called a join point, that is, the point in the component at which 
another component is added. The operation © defines component 
composition. The function fa r is a fixpoint combinator used for 
closing, or sealing, an open and potentially composed component. 

Combining monads with mixins When combined with monads, 
mixins allow us to model a simple form of AOP-like advice [17], 
However, the control-flow patterns of programs using mixins are 
complex. For instance, consider the following memoization com- 
ponent and a monadic fibonacci function. 

memo :: § M ( Map Int Int) m => Mixin ( Int — » m Int) 
memo proceed x = 
do m <— get 

if member x m 
then return (m ! x) 
else do y <— proceed x 
in' <— get 
put ( insert x y m') 
return y 

fib :: Monad m => Mixin ( Int — » m Int) 
fib proceed n = 
ease n of 

0 — > return 0 

1 — > return 1 

— » do y «— proceed (n - 1) 
x <— proceed (n - 2) 
return (x + y) 

We can instantiate different monads, using the corresponding run 
functions of Figure 1, to recover variations of the fibonacci func- 
tion. For example, the identity monad recovers the effect-free func- 
tion while a fast fibonacci function is obtained by adding the memo 
advice and suitably instantiating the state monad: 

slowfib :: Int — > Int 
slowfib = rurii o fix fib 

faslfib :: Int —> Int 

faslfib = evalM empty o fix (memo © fib) 

evalM :: s — > S T s I a — > a 

evalM s m = runl $ runS T m s >= return o fist 

Another component for profiling is 

prof :: S M Int m => Mixin (a — > m b) 
prof proceed x = do c *— get 

put (c + 1 ) 
proceed x 

which allows us to count the number of calls to the fibonacci 
function 

projfib = evalM 0 o fix ( prof © fib) 

Transformer Conflicts Of course, we would also like to profile 
the memoized fibonacci function to get an idea of how much more 
efficient it is. 

profmemofib :: Int — > § x Int (S T (Map Int Int) I) Int 
profmemofib =fix (prof © memo © fib) 

Unfortunately, the type checker complains that Int and Map Int Int 
are distinct types. The problem is that there are two uses of get 
in our components: one in prof', and another in memo. Due to 
automatic lifting, both get methods read the state from the same 
top-level S T , which happens to contain an Int value. This is the 
right thing to do for prof, but wrong for memo that expects a value 
of type Map Int Int. 


6.2 Zipping Mixins 

The problem above can be solved using the monad zipper to pro- 
vide a new composition operator ® for mixins. 

(®) :: Mixin (a — » ti (t 2 m) b) 

— > Mixin (a — > (tj > f?) m b) 

— > Mixin (a — > (t 2 m) b) 

Ci ® c 2 = /I proceed x — » cj (T o c 2 (i ° proceed)) x 

This combinator associates the left-to-right order of components 
with a corresponding top-to-bottom order of monad layers. Here 
component c 2 focuses on the current layer, and c 2 looks one posi- 
tion down - that’s why we have to bring proceed down (f) to its 
level and shift the whole back up (f) to the current level. 

This combinator is very useful whenever we have a set of com- 
ponents that uses a disjoint set of monads (that is, each component 
will use different monads). No additional work is needed to make 
the two state transformers of prof and memo happily coexist. 

profmemofib :: Int — » § T Int (§ T (Map Int Int) (I T I)) Int 
profmemofib = fix (prof 0 memo 0fib) 

Note that every component has its own transformer, notably I T for 
fib, and we use the base monad I at the bottom of the stack. 

6.3 Views and Masks 

When using mixins we generally need the full power of bi- 
directional views to shift between two isomorphic monads. To 
make this shifting convenient we use the following combinator: 

fmask (Monad m, Monad n) 

=> (n m m) — » Mixin (a —> n b) — > Mixin (a — » m b) 
fmask v mix proceed = from v o mix (to v o proceed) 
mix ‘ uses m ‘ names = fmask (structure names) mix 

The fmask combinator takes a view v and applies it to a mixin mix 
executing the to function after proceeding and the from function 
after the mixin. Nominal views are applied with uses,,,. 

To demonstrate the application of masks and views on monadic 
mixin components, consider a simple assertion component that is 
used to check the output of a computation. We will show how this 
component is useful for checking whether the result of computing 
the fibonacci function has overflowed or not. 

assertDump :: (E M String m, Rm s m. Show a. Show b. Show s) 
=> (b — » Bool) — » Mixin (a —> m b) 

The assertDump component applies an assertion (a function of 
type b — > Bool) to the output of proceed ’s computation. If the asser- 
tion fails, an error is raised. The error message includes information 
on the state at the time of the error, to facilitate debugging. 

This assertDump component allows the creation of another vari- 
ant of the fibonacci program where, along with memoization and 
profiling, we also check for overflow and dump the memo table 
when overflow happens. Because we may be interested in recov- 
ering from the overflow (for example, by changing the represen- 
tations of the inputs and outputs from Int to Integer) and continu- 
ing the computation, the exception layer should be at the top of the 
stack. Also, profiling works better if it is executed before memoiza- 
tion, so the profiler component should be in between assertDump 
and memo. However, assertDump requires access to the monadic 
layer with the memo table. In order to combine these components 
together we should make sure that all the constraints are satisfied. 

Because there is no simple one-to-one correspondence between 
mixins and stack layers, we use the nominal approach. In addition, 
the r imposes a read-only view on the Memo state for assertDump. 

test :: Int — > ((Either String Int, Int), Map Int Int) 
test = myEval o 



fix ( assertDump (> 0) ‘fmask‘ r ‘ uses m ‘ Err & Memo 
© prof ‘uses m ‘ Prof 

© memo ‘uses„,‘ Memo 

© fib) 

myEval m = runl $ runT § T Memo empty 
S runTSj Prof 0 
S runTEj Err $ m 

6.4 Monadic Mixins in Practice: Search Combinators 

Schrijvers et al. [24] present a compelling application of the 
monadic mixins. They provide a Domain Specific Language (DSL) 
for expressing a complex search heuristic as a concise combination 
of primitive combinators. In their implementation, each primitive 
combinator corresponds to a monadic mixin component. The ad- 
vantage and novelty is twofold: 1) flexibility because the user is 
able to combine combinators any way she wants, and 2) extensibil- 
ity because the system developer is able to add new combinators 
without touching the existing ones. 

To fit in with the Gecode C++ Constraint Programming li- 
brary and for performance reasons, a staged approach is taken. The 
Haskell mixin components are code generators that collaborate to 
produce the C++ code for the overall search algorithm. For ex- 
ample, a search heuristic tailored to solving radiation therapy plan- 
ning problems [1] of typical size consists of 20-30 monadic mixins, 
each with their own monad transformer, that collaborate to produce 
around 2000 lines of specialized C++ code. We are not aware of 
other Haskell projects with comparable monad stack sizes. 

Effect Encapsulation Additionally to the techniques already intro- 
duced by us earlier in this section, the search combinators applica- 
tion employs a technique that facilitates the dynamic composition 
of many mixin components from a parsed specification string: each 
component encapsulates its own effect. Even statically this encap- 
sulation makes sense. After all, the type of a monad stack with 20 
layers is rather unwieldy. 

The Component datatype below illustrates the encapsulation 
technique on the simple Mixin type. 6 The effect t? of the component 
is existentially quantified to hide it, and the included run function 
allows eliminating it. 

data Component a b = V ti-MoncidTrans t 2 => 

Component {behavior :: V f, infMonadTrans tj, Monad m) 
=> Mixin (a — » ( t; > f?) m b) 

, run : : V m x. Monad m => /> m x — * m x } 

While not all monad transformers support a run function of the 
above type, it is convenient and sufficient for our search combina- 
tors. For more details on the encapsulation technique and a more 
general form of run function, we refer to [22, Section 3.4], 

Performance Considerations We have not performed any sys- 
tematic benchmarks yet, but do have a few observations on perfor- 
mance. Because it is defined as a newtype, wrapping and unwrap- 
ping the monad zipper does not add any space or runtime overhead. 
It does generate different type class dictionaries for the different 
components, and depending on the amount of inlining this either 
happens once (statically) or repeatedly for each invocation of a 
component (dynamically). The latter scenario notably arises when 
the effect types are existentially quantified. We have observed that 
this repeated creation of dictionaries puts compositions with around 
60 monad transformers out of reach. In conclusion, gracefully and 
predictably scaling performance to monad stack sizes well beyond 
30 layers is an open challenge. 


6 The mixin record type of search components is too elaborate to show here. 


7. Discussion and Related Work 

7.1 The Haskell Setting 

Our approach makes use of two key ingredients, monadic types and 
constrained polymorphism, which are both available in Haskell. 
The combination of these provides the necessary flexibility for 
effectful components to be adapted to many different settings. 

One important advantage of using of Haskell is type-inference. 
In a setting like ours, where types can be relatively complex, type- 
inference is a blessing and allows most types to be inferred auto- 
matically. Indeed, although we have often used type annotations 
in our examples for documentation, those annotations are (for the 
most part) not necessary. 

While Haskell provides the two necessary ingredients, there is 
potential for transferring the presented ideas to other settings. The 
monad zipper, views and structural masks have category theory 
interpretations and as such are of a more general nature. Indeed, 
they are relevant and adaptable to other settings that deal with 
explicit effects. Haskell-specific implementation aspects can find 
alternative counterparts in other languages. For instance, in Scala 
implicits can replace type classes [16]. The type-class tricks to 
look up names for nominal masks, popularized by Kiselyov [12], 
could be considerably simplified in a dependently typed language. 
Finally, a language design that natively supports the presented 
concepts is another option. 

7.2 Effect Systems and Modular Monads 

Effect systems (also known as type-and-effect systems) [14] form 
a popular non-monadic approach for making side effects explicit. 
However, they only describe (and do not define) programs that al- 
ready have a meaning independent of the effect system. Hence, 
the effect annotations cannot adapt component behavior. Filin- 
ski’s MultiMonadic MetaLanguage (M 3 L) [7, 8] does embrace the 
monadic approach, but uses subtyping (or subeffecting) to com- 
bine the effects of different components. The subtyping relation is 
fixed at the program or language level, which does not provide the 
adaptability we achieve with constrained polymorphism. 

Since Moggi [15] proposed monads to model side-effects, and 
Wadler [30] popularized them in the context of Haskell, various 
researchers (e.g., [11, 26]) have sought to modularize monads. 
Monad transformers emerged [3, 13] from this process, and in 
later years various alternative implementation designs, facilitating 
monad (transformer) implementations, have been proposed, such 
as Filinksi’s layered monads [6] and Jaskelioff’s Monatron [10], 

In this paper, we rely on several of Monatron’s techniques for 
implementing monad transformers. However, so as not to confuse 
the reader, we have incorporated the necessary techniques form 
Monatron in the familiar setting of the Monad Transformer Li- 
brary 7 (MTL). 

In our variant of the MTL, 8 monad transformers have to supply 
two additional operations, tmap and mw, which are inspired by 
Monatron: 

class MonadTrans t where 

lift :: Monad m => m a — » t m a 
tmap :: ( Monad m. Monad n) 

=> (ix.m x —* n x) — * t m a —* t n a 
mw :: Monad m => MonadWitness t m 

Here, tmap allows transforming the monad underneath a trans- 
former t. We have two uses for this additional operation: 


7 which implements the original ideas of [13] 

8 available at http://users.ugent.be/-tschrijv/Haskell/ 
MTLzipper .tgz. 



• Our first use, just like in Monatron, is to lift control opera- 
tors like catchError and local through other transformers; in 
the original MTL these operations could not be lifted. In our 
setting, it enables us to implement these control operators ap- 
propriately for the zipper (>). 

For instance, here is the zipper implementation of the local 
operator from the Rm type class: 

local f m = Z T $ tmap (local f) $ ruriZr? m 

• The second use, already covered in Section 4, is for the im- 
plementation of the hmap function of the MonadCategory type 
class. 

The mw method encodes the property im. Monad m =t> Monad ( t m) 
as a GADT witness. 

data MonadWitness t in where 

MW :: Monad ( t m) => MonadWitness t m 

In the original MTL, this property holds informally, but is neither 
enforced nor exploitable. We require this property to implement 
many of the zipper’s operations. For instance, the return method 
for the zipper is defined as: 

return x = case (mw :: MonadWitness t 2 m) of 
MW — » case (mw :: MonadWitness ti (t 2 m)) of 
MW —* Zt $ return x 

In the Monatron design, the property is directly conveyed to the 
type checker in the form of a single type class instance: 

instance (Monad m, MonadTrans t) => Monad (t m) where ... 

However, this approach is not compatible with the MTL design. 
Hence, our GADT witness approach. 

A limitation of tmap , both in Monatron and our MTL variant, is 
that it only works for covariant monad transformers. For instance, 
the contravariant continuation monad transformer cannot imple- 
ment this operation. 

7.3 Tag-indexed monads 

It has been independently suggested by Snyder & Alexander [25] 
and Piponi [19] that indexing monad transformers with a type- 
level tag improves their convenience and robustness to changes. 
MTLX [25] is a monad transformer library that embodies this idea: 
automatic lifting ambiguities are resolved by tags. For example, 
consider the programs pi and p 2 written, respectively, in the MTL 
and MTLX. 

Pi :: (§ M Int m, § M Bool m) => m Int 
pi = do b <— get 
x <— get 

return (if b then x else 0) 

p 2 :: (§ M Ixi Int m , § M Ix 2 Bool m) => m Int 
p 2 = do b <— get lx, 
x <— get lx 2 

return (if b then x else 0) 

The;?; program does not type-check because the functional depen- 
dencies in the type class S M require that the state type is uniquely 
determined by m, but in this program two different state types are 
used. The program p 2 , written for MTLX, solves this issue by using 
a § M class with a third type parameter, which is used to index the 
monad and determine the state type (along with the monad type), 
which avoids the conflict in;?;. 

The main advantage of indexed monads is that they simplify the 
implementation of monadic components with multiple instances 
of the same effect. However tags commit to global names, which 


restricts reuse. If the lack of flexibility is not an objection, tags are 
a good solution. However, when the primary focus is flexibility and 
reusability, tags have important drawbacks compared to the monad 
zipper and monad views. In the MTLX approach, it is possible to 
abstract over the tag in order to be able to choose the monad layer 
later. For example: 

inc : : (§ M ix Int m) => ix — > m Int 

inc ix = do [x <— get ix;put ix (x +1); return (jr + 1)) 

This value-level abstraction is more verbose than the monad zip- 
per's type-level abstraction; it is an invasive approach that requires 
the component to be written with tags in mind. Moreover, for the 
price of value-level abstraction, we get a lot more expressivity front 
views: restricting access to layers is not possible with tags. Finally, 
a predefined set of tags is unsuitable when components are gen- 
erated and composed dynamically, as in our search combinators 
application. 

Ultimately, indexed monads and our techniques are useful for 
solving different problems and it is possible to get the benefits 
of both approaches by combining some of the techniques. For 
example, if we added monad views and the monad zipper to MTLX, 
we could use views to virtualize the tag names, by renaming or even 
removing the tags to suit the client’s monad stack, and effectively 
acting as a scoping mechanism for the name tags. 

7.4 Monadic Components 

Many works have identified a need for reusable monadic compo- 
nents, but have not addressed the limitations related to monad stack 
management. Mixins were introduced by Cook [4] as a functional 
form of inheritance. Brown and Cook [2] first considered monadic 
mixins for memoization, while Oliveira et al. [17] model arbitrary 
AOP-style advice with them and show how to reason about interfer- 
ence between two components based on equational reasoning and 
parametricity. Our work should enable a generalization of the latter 
reasoning results to scenarios with arbitrarily many components. 
Prehofer [20] also considers a monadic model for FOP, which is 
not based on mixins. 

The techniques presented in this paper can be used to improve 
the current state-of-the-art approaches to modular interpreters [5, 
13, 27]. We describe a modular effectful interpreter case study, 
which uses the techniques presented in this paper, in a separate 
manuscript [23]. 

8. Conclusion 

The current-state-of-the-art in monad stack management is too re- 
strictive to effectively support reusable monadic components. The 
monad zipper provides the basic mechanism to lift these restric- 
tions, and enables more powerful solutions such as structural and 
nominal masking. Views unite masks and other monad transforma- 
tions in a single framework for adapting monadic components to a 
wide range of monad stacks. 
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A. TWith Instances 

In this appendix, we provide the implementation of the overloaded 
structure function as a set of five overlapping instances for the 
TWith class. Three instances cover the three possible cases and two 
instances resolve overlaps between the three possible cases. 

Although the implementation below may look daunting to the 
uninitiated, it relies only on folklore type-level programming tech- 
niques. Moreover, the user is never directly confronted with these 
instance implementations. 

— [1] tag at the top 

instance ( Monad m, m~n) => TWith tag n (T t tag m) where 
structure _ = t 

— auxiliary clause, to resolve overlap between [1] and [3] 
instance ( Monad m, m~t n, MonadTrans t) 

=> TWith tag m (T t tag ( t n)) where 
structure _ = t 

— [2] tag in focus 

instance ( Monad m, Monad n , MonadTrans t, m~t n) 

=> TWith tag m (( t > T t tag) n) where 

structure _ = case (mw :: MonadWitness t (T t tag n)) of 
MW hmap t 

— auxiliary clause, to resolve overlap between [2] and [3] 
instance (Monad (t' n), Monad m, Monad n, MonadTrans t, 

m~(((t > T t tag ) > t') n), MonadTrans t') 

=> TWith tag m ((t > T t tag) (t' n )) where 

structure _ = case (mw :: MonadWitness t' n) of 
MW — > ■ 

— [3] shift focus down 

instance (Monad (tO (tj n)). Monad m. Monad n, 

TWith tag m (( tO > ti) n), MonadTrans tO, MonadTrans ti) 
=> TWith tag m (tO (ti n)) where 
structure tag = 

case (mw :: MonadWitness t/ n) of 



MW — > case (mw :: MonadWitness tO ( ti n )) of 
MW — » ■ • structure tag 

The above instances make use of the following auxiliary functions 

t : : View (~») => m T t tag m 
t = view T x run T x 

■ _1 = view | t 



